Review and validate (or generate, if necessary) the set of data principles. These will normally form part of an
overarching set of architecture principles. Guidelines for developing and applying principles, and a sample set of data
principles, are given in Part
III, Architecture Principles .
Select relevant Data Architecture resources (reference models, patterns, etc.) on the basis of the business drivers,
stakeholders, concerns, and Business Architecture.
Select relevant Data Architecture viewpoints (for example, stakeholders of the data - regulatory bodies, users,
generators, subjects, auditors, etc.; various time dimensions - real-time, reporting period, event-driven, etc.;
locations; business processes); i.e., those that will enable the architect to demonstrate how the stakeholder concerns
are being addressed in the Data Architecture.
Identify appropriate tools and techniques (including forms) to be used for data capture, modeling, and analysis, in
association with the selected viewpoints. Depending on the degree of sophistication warranted, these may comprise
simple documents or spreadsheets, or more sophisticated modeling tools and techniques such as data management models,
data models, etc. Examples of data modeling techniques are:
-
Entity-relationship diagram
-
Class diagrams
-
Object role modeling
Determine Overall Modeling Process
For each viewpoint, select the models needed to support the specific view required, using the selected tool or method.
Examples of data models include:
-
The Department of Defense Architecture Framework (DoDAF) Logical Data Model
-
ARTS Data Model for the Retail industry
-
Energistics Data Model for the Petrotechnical industry
Ensure that all stakeholder concerns are covered. If they are not, create new models to address concerns not covered,
or augment existing models (see above).
The recommended process for developing a Data Architecture is as follows:
-
Collect data-related models from existing Business Architecture and Application Architecture materials
-
Rationalize data requirements and align with any existing enterprise data catalogs and models; this allows the
development of a data inventory and entity relationship
-
Update and develop matrices across the architecture by relating data to business service, business function, access
rights, and application
-
Elaborate Data Architecture views by examining how data is created, distributed, migrated, secured, and archived
Identify Required Catalogs of Data Building Blocks
The organization's data inventory is captured as a catalog within the Architecture Repository. Catalogs are
hierarchical in nature and capture a decomposition of a metamodel entity and also decompositions across related model
entities (e.g., logical data component -> physical data component ->] data entity).
Catalogs form the raw material for development of matrices and diagrams and also act as a key resource for portfolio
managing business and IT capability.
During the Business Architecture phase, a Business Service/Information diagram was created showing the key data
entities required by the main business services. This is a prerequisite to successful Data Architecture activities.
Using the traceability from application to business function to data entity inherent in the content framework, it is
possible to create an inventory of the data needed to be in place to support the Architecture Vision.
Once the data requirements are consolidated in a single location, it is possible to refine the data inventory to
achieve semantic consistency and to remove gaps and overlaps.
The following catalogs should be considered for development within a Data Architecture:
-
Data Entity/Data Component catalog
The structure of catalogs is based on the attributes of metamodel entities, as defined in Part IV, Content Metamodel .
Identify Required Matrices
Matrices show the core relationships between related model entities.
Matrices form the raw material for development of diagrams and also act as a key resource for impact assessment.
At this stage, an entity to application systems matrix could be produced to validate this mapping. How data is created,
maintained, transformed, and passed to other applications, or used by other applications, will now start to be
understood. Obvious gaps such as entities that never seem to be created by an application or data created but never
used, need to be noted for later gap analysis.
The rationalized data inventory can be used to update and refine the architectural diagrams of how data relates to
other aspects of the architecture.
Once these updates have been made, it may be appropriate to drop into a short iteration of Application Architecture to
resolve the changes identified.
The following matrices should be considered for development within a Data Architecture:
-
Data Entity/Business Function (showing which data supports which functions and which business function owns which
data)
-
Business Service/Information (developed during the Business Architecture phase)
-
System/Data (developed across the Application Architecture and Data Architecture phases)
The structure of matrices is based on the attributes of metamodel entities, as defined in Part IV, Content Metamodel .
Identify Required Diagrams
Diagrams present the Data Architecture information from a set of different perspectives (viewpoints) according to the
requirements of the stakeholders.
Once the data entities have been refined, a diagram of the relationships between entities and their attributes can be
produced.
It is important to note at this stage that information may be a mixture of enterprise-level data (from system service
providers and package vendor information) and local-level data held in personal databases and spreadsheets.
The level of detail modeled needs to be carefully assessed. Some physical system data models will exist down to a very
detailed level; others will only have core entities modeled. Not all data models will have been kept up-to-date as
applications were modified and extended over time. It is important to achieve a balance in the level of detail provided
(e.g., reproducing existing detailed system physical data schemas or presenting high-level process maps and data
requirements, highlight the two extreme views).
The following diagrams should be considered for development within a Data Architecture:
-
Class diagram
-
Data Dissemination diagram
-
Data Lifecycle diagram
-
Data Security diagram
-
Data Migration diagram
-
Class Hierarchy diagram
Identify Types of Requirement to be Collected
Once the Data Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by
formalizing the data-focused requirements for implementing the Target Architecture.
Within this step, the architecture engagement should identify types of requirement that must be met by the architecture
implementation, including:
-
Functional requirements
-
Non-functional requirements
-
Assumptions
-
Constraints
-
Domain-specific Data Architecture principles
-
Policies
-
Standards
-
Guidelines
-
Specifications
|
